Device Representation and Reasoning with Affective Relations

ly , reasoning w i t h affective relations proceeds by examin ing the ou tpu t of the device to determine the state of key components, and then propagat ing this i n format ion through the affective relations to deduce the state of other components. Act ions are then performed based on the nature of the alarm messages f rom the device and the states of the components. To make this more concrete the rest of this section presents an example of an affective relat ion model. 2.1 D e v i c e R e p r e s e n t a t i o n The key elements of our device model are 1) a set of basic classes (e.g., Device), 2) a set of diagnostically mot ivated affective relations re lat ing device components, 3) a set of relations relat ing other classes in the model , and 4) a set of properties and general relationships specifying the semantics of the relations, i.e., the knowledge that is impl ic i t in any expl ic i t ly specified knowledge. See Figure 1 for a knowledge level [Newell, 1982] description of a port ion of the device model . (See [ A T T , 1995] for a symbol level description of a much larger por t ion of the device model.) Affective relations l ink components to other components in diagnostically useful ways. For example, i r amed ia te -pa r t -o i means that a direct subcomponent/component relationship exists between two devices. P a r t o f reflects direct as well as transi t ively closed subcomponent/component relations, while its inverse subpa r t reflects direct and transit ive component/subcomponent relations. Depends-on means that the correct funct ioning of a device depends on the correct funct ioning of another device; dependent represents the inverse relation between the two devices. Standby means that if one device fails, its standby partner w i l l take over automat ical ly ; it also means that reliable operation is jeopardized if one device fails. Other relations l ink devices to other classes in the model. S e l f a l a r m means that a device is signaling an a larm. However, a problem w i th one device may not necessarily cause that device to itself signal an a larm; instead, the problem may affect a second device, causing it to signal an a larm. P a r t a l a r m and dependen t -a l a rm l ink devices to alarms signaled by other devices. P a r t a l a r m relates a device to an a larm on another device when the a larming device is a s u b p a r t of the device; dependen t -a l a rm relates devices to alarms based on depends-on. Devices are either f u n c t i o n a l or not. If a device depends on another device that is not funct ional , the dependent device is also not funct ional . If a device is in s i m p l e x mode, it means that none of the device's standbys are funct ional . To i l lustrate the use of these relations, we examine in some detai l a d ig i ta l to l l switching system known as a 4ESS switch. A por t ion of the basic class hierarchy is shown in Figure 2. The class Device is broken down into a series of 4ESS-specific subclasses. Each major type of component of the 4ESS (down to the level of field-replaceable units) adds a class to the general device ontology shown in Figure 1. Figure 3 shows how some of the key port ions of the model of the 4ESS switch are instant iated using the general and domain-specific port ions of the ontology shown We use typewriter font for r e l a t i o n s and sans serif for classes (and their members). To eliminate jargon, hardware component names have been replaced with ABC, etc.